home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0056 / 614.txt < prev    next >
Text File  |  1997-04-16  |  16KB  |  400 lines

  1. INFO-ATARI16 Digest         Mon,  6 Nov 89       Volume 89 : Issue 614
  2.  
  3. Today's Topics:
  4.            >RE> Atrocious Atari Dealer (Zephyr/Microworld)
  5.                             archive sites
  6.    DOES ATARI LASER PRINTER WORK ONLY WITH MORE THAN 1 MEG RAM STs:
  7.                          floppy stepping rate
  8.                  GEMDOS Extended Argument Spec (LONG)
  9.                         GNU C and sizeof(int)
  10.                            Micro Emacs 3.10
  11.                         Prolog 10, Common LISP
  12.                           TOS, Zoo, or Zen?
  13.                     TOS, Zoo, or Zen? (DTA stuff)
  14.    Trying to read an Atari St Gem-Dos disk on a Mac SE using FD/HD
  15.                                   TT
  16.                             unix on the TT
  17. ----------------------------------------------------------------------
  18.  
  19. Date: 7 Nov 89 01:46:53 GMT
  20. From: tahoe!wheeler!mikew@apple.com  (Mike Whitbeck)
  21. Subject: >RE> Atrocious Atari Dealer (Zephyr/Microworld)
  22.  
  23. In article <8911060807.AA19911@ucbvax.Berkeley.EDU> UUCJEFF@ECNCDC.BITNET (jeff
  24.  beer) writes:
  25. !!
  26. !!Once home, I was filing the receipt away when I noticed that the total on
  27. !!the receipt and the total on the charge slip didn't match...  Upon closer
  28. !!inspection, I discovered that I couldn't decipher the receipt at all!
  29. !!
  30. !I would protest this with your credit card company, showing the original
  31. !receipt being different than the charge ticket.  It is obvious Microworld is
  32. !a shady outfit, and you should use all avenues to put persure on them.
  33. !
  34. !I will definitely stay away from Zephyr.
  35. !
  36. !Jeff
  37.  
  38. DITTO! I too have had trouble with these guys! But never again.
  39. (Once fooled shame on them- twice fooled shame on me)
  40.  
  41. ------------------------------
  42.  
  43. Date: 7 Nov 89 01:57:52 GMT
  44. From:
  45.  cs.utexas.edu!samsung!shadooby!sharkey!math.lsa.umich.edu!hyc@tut.cis.ohio-stat
  46. e.edu  (Howard Chu)
  47. Subject: archive sites
  48.  
  49. In article <1707@quiche.cs.mcgill.ca> depeche@quiche.cs.mcgill.ca (Sam Alan
  50.  EZUST) writes:
  51. %I am trying to get ahold of FATSPEED. On xanth.cs.odu.edu the atari
  52. %directory is empty.
  53. %on him1.cc.umich.edu I downloaded about four files and all of the
  54. %ones are .arc files which I can't extract due to bad headers.
  55. %
  56. %does anyone know
  57. %1] why xanth's atari directory is empty?
  58. %2] why I can't de-arc anything from him1?
  59. %3] how I can get FATSPEED?
  60. %
  61. %thanks in advance.
  62.  
  63. I just checked, the copy of FATSPEED.ARC on HIM1 is perfectly fine.
  64. You must not have downloaded it in binary mode. Or you must not have
  65. ftp'd it in binary mode. No other explanation.
  66.  
  67. --
  68.  -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1]
  69.  and You Too can have a Personal Electronic Relationship with God!
  70.  
  71. ------------------------------
  72.  
  73. Date: 6 Nov 89 20:23:21 GMT
  74. From: imagen!atari!apratt@ucbvax.Berkeley.EDU  (Allan Pratt)
  75. Subject: DOES ATARI LASER PRINTER WORK ONLY WITH MORE THAN 1 MEG RAM STs:
  76.  
  77. alderaan@tubopal.UUCP (Thomas Cervera) writes:
  78. >(Imran Anwar) writes:
  79. >>      DOES ATARI LASER PRINTER NEED MORE THAN 1 MEG RAM ?
  80. >  Yep.
  81.  
  82. Nope.  You can use the Diablo 630 emulator to get text output using any
  83. GDOS font using practically no memory.  While the page is being
  84. imaged, the CPU is building band-buffers, keeping ahead of the beam.
  85.  
  86. You can't get GDOS output: the GDOS SLM driver needs to image the page
  87. all at once, then print it, because it can't image bands fast enough
  88. (they can be arbitrarily complex!).
  89.  
  90. Even the Diablo output has limits: if a line or group of lines
  91. is too complex, it can't keep up.  This isn't normally a problem,
  92. but something like nroff/tbl output, with lots of overstrikes
  93. and reverse linefeeds can cause trouble.
  94.  
  95. The Diablo emulator will also draw horizontal and vertical lines and
  96. print bitmapped images anywhere on the page, as large as will fit in
  97. memory, but it will magnify at 1x1, 2x2, and 4x4 printer pixels per bit
  98. in memory.
  99.  
  100. ============================================
  101. Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
  102. reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt
  103.  
  104. ------------------------------
  105.  
  106. Date: 6 Nov 89 18:27:47 GMT
  107. From:
  108.  cs.utexas.edu!usc!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!larry!polyslo!vlsi
  109. 3b15!saic.com!steveg@tut.cis.ohio-state.edu  (stephen harold goldstein)
  110. Subject: floppy stepping rate
  111.  
  112. Try using the following program in your AUTO folder.
  113.  
  114. It works just fine with my 'official' (04 06 19 89) Rainbow TOS,
  115. And sets the floppy step/seek rate to 6ms.
  116.  
  117. (Many thanks to the netter who orginally sent this to me when my old
  118.  step rate program 'died' upon TOS 1.4 installation...)
  119.  
  120. Stephen Goldstein     steveg@saic.com
  121. My first Atari system? A 24K Atari 800, Rev. A ROMS, C(not G)TIA graphics
  122. Disclaimer:  That's not what I said.
  123.  
  124. -------- cut here --------
  125. begin 644 pcf554.prg
  126. M8!H   $B                             $AY    C#\\  E.05Q/0J<_
  127. M/  @3D%<3R\ /SP ("!X!/(~*  "3D%<3[Y\ 0!G  ! OGP! F<  #!"9S\\
  128. M  $_/  I3DY<3S\\__\_/  !/SP *4Y.7$]*0&<  !Q(>0   --@   80?@*
  129. M3&    9!~ H&0F@ !DAY    ~C\\  E.05Q/0F=.04K\"@T@&W @(" @(" @
  130. M(%!#1C4U-"!D<FEV97(@(" @(" @(!MQ"@T@0V]P>7)I9VAT(+T@,3DX."P@
  131. M071A<FD@0V]R<"X*#0 @&W @0V]U;&1N)W0@<V5T(#9M<R!S965K(')A=&4A
  132. M(!MQ"@T*#0 @&W @(" V;7,@<V5E:R!R871E('-E="!O;B!".B @(!MQ"@T*
  133. M#0       EX:
  134. 8
  135.  
  136. end
  137.  
  138. --
  139.  
  140. Stephen Goldstein     steveg@saic.com
  141. My first Atari system? A 24K Atari 800, Rev. A ROMS, C(not G)TIA graphics
  142. Disclaimer:  That's not what I said.
  143.  
  144. ------------------------------
  145.  
  146. Date: Mon, 6 Nov 89 20:43:19 EST
  147. From: csrobe@cs.wm.edu (Chip Roberson)
  148. Subject: GEMDOS Extended Argument Spec (LONG)
  149.  
  150. I was looking over the code in your article on the EAS posted in digest
  151. V89 #595 trying to comprehend the method, when I think I discovered
  152. a typo.  It is in the while loop that is supposed to "put as much in
  153. the tail as will fit":
  154.  
  155.         while ((lentail < 126) && (penvargs < pchildenv))
  156.  
  157. lentail is initialized to 0 above and never changed in the body of
  158. the loop.  Given that the tail cannot be longer than 125 bytes, I am
  159. supposing that lentail should either be post-incremented here, or
  160. incremented in the body of the loop?  Is this correct?
  161.  
  162. Thanks,
  163. -c
  164. -=- Charles S. Roberson          ARPANET:    csrobe@cs.wm.edu           -=-
  165. -=- VA Remote Sensing Study      UUCP:       ...!uunet!cs.wm.edu!csrobe -=-
  166. -=- Dept of Comp. Sci.           Compu$erve: 71500.2056@compuserve.com  -=-
  167. -=- College of William and Mary  BIX:        csrobe                     -=-
  168. -=- Williamsburg, VA 23185       Ma Bell:    (804) 253-4393             -=-
  169.  
  170.  Fur Thought:  Put on a fur and slip into something dead.
  171.  
  172. ------------------------------
  173.  
  174. Date: 6 Nov 89 20:25:45 GMT
  175. From: imagen!atari!apratt@ucbvax.Berkeley.EDU  (Allan Pratt)
  176. Subject: GNU C and sizeof(int)
  177.  
  178. stephen@oahu.cs.ucla.edu (Steve Whitney) writes:
  179. >rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes:
  180. >>Has anyone made a 16-bit GCC and library and done a comparison?
  181. >You can always use this simple hack:
  182. >#define int short
  183. >But you have to be careful with constants.  If you pass 3 as an argument
  184. >to a routine expecting a 16 bit integer, it will pass 00 00 00 03 instead
  185. >of 00 03.  To get around that, pass your constants as (short)3 instead.
  186.  
  187. ...or you can use -mshort on the GCC command line.  ...or you can use
  188. prototypes, which cause the compiler to cast actuals to the types of
  189. the formals (and generate warnings, etc., based on that).  Since 3 is a
  190. valid short as well as int, there's no problem.
  191.  
  192. ============================================
  193. Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
  194. reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt
  195.  
  196. ------------------------------
  197.  
  198. Date: 6 Nov 89 15:18:11 GMT
  199. From:
  200.  cs.utexas.edu!samsung!rex!uflorida!stat!vsserv!prism!iadt3tb@tut.cis.ohio-state
  201. .edu  (T. Terrell Banks)
  202. Subject: Micro Emacs 3.10
  203.  
  204. ?Just what is the difference between v3.10 and 3.9?
  205. ?
  206.               .8
  207.  
  208.     It's gonna be that kind of week!
  209.  
  210.              Cheers,
  211.                  TB
  212.  
  213. --
  214. T. Terrell Banks  uucp:  ? 'insert a backbone name here' ?!gatech!prism!iadt3tb
  215. Georgia Insitute of Technology - I.S.A.      Internet: iadt3tb@prism.gatech.edu
  216. 190 Third Street NW                                     Bitnet : iadt3tb@gitvm1
  217. Atlanta, Georgia 30332-0185
  218.  
  219. ------------------------------
  220.  
  221. Date: 7 Nov 89 02:03:54 GMT
  222. From:
  223.  quanta.eng.ohio-state.edu!raksha.eng.ohio-state.edu!rob@tut.cis.ohio-state.edu
  224.  (Rob Carriere)
  225. Subject: Prolog 10, Common LISP
  226.  
  227. In article <36500071@silver> jkain@silver.bacs.indiana.edu writes:
  228. >
  229. >/* ---------- "Prolog 10, Common LISP" ---------- */
  230. >I address this especially to continental European ST users:
  231. >
  232. [message in German deleted]
  233. >Well isn't *this* a fine how-do-you-do?  Even if we live in the U.S.
  234. >perhaps we would like to know what you're saying.
  235. [Spanish(?) reply deleted]
  236.  
  237. Even better, he is assuming Europe == Germany.  Think about the knee-jerk
  238. potential here!
  239.  
  240. Anyway,
  241. "I know Cambridge LISP and MProlog, but they are not what I am looking for.
  242.  I am sorry that my German isn't very good, but since so may ST users are
  243.  German, I believe that they don't want to always read English here."
  244. >     David Megginson, Centre for Medieval Studies, Toronto
  245.  
  246. No cause for paranoia, meseems :-)
  247. SR
  248.  
  249. ------------------------------
  250.  
  251. Date: 6 Nov 89 21:15:15 GMT
  252. From: imagen!atari!kbad@ucbvax.Berkeley.EDU  (Ken Badertscher)
  253. Subject: TOS, Zoo, or Zen?
  254.  
  255. covertr@force.UUCP (Richard E. Covert) writes:
  256.  
  257. | Will MWC have to be changed to support the new TOS 1.4??
  258.  In terms of DTA management, no.  The point of my original posting was
  259. something that went out in the Developer Rainbow TOS relese notes:
  260. GEMDOS DTA handling has changed.  If you relied on undocumented features
  261. of GEMDOS DTA handling, you may lose under Rainbow TOS.  The thing that
  262. may catch you unawares is that GEMDOS _will_ trash your DTA after an
  263. Fsnext() that fails.  Apparently, previous GEMDOS versions left the
  264. filename part of the DTA alone after a failed Fsnext().  So if you're
  265. searching for a bunch of files, copy what you need out of the DTA
  266. before each Fsnext() operation, and you won't get bitten.
  267.  
  268. --
  269.    |||   Ken Badertscher  (ames!atari!kbad)
  270.    |||   Atari R&D System Software Engine
  271.   / | \  #include <disclaimer>
  272.  
  273. ------------------------------
  274.  
  275. Date: 6 Nov 89 20:39:42 GMT
  276. From: imagen!atari!apratt@ucbvax.Berkeley.EDU  (Allan Pratt)
  277. Subject: TOS, Zoo, or Zen? (DTA stuff)
  278.  
  279. Let me clear up what Ken said:
  280.  
  281. Point 1: You can't use the private part of the DTA, and if you do, your
  282. program won't work on TOS 1.4 because the private part of the DTA
  283. changed entirely.  Even if you figure out what it's used for, you
  284. will lose when a new TOS comes along and blows your program up
  285. again.
  286.  
  287. Point 2: If a Fsnext() returns ENMFILES ("no more files"), the public
  288. part of the DTA contains nothing useful.  It does not, for example,
  289. contain the data from the file which matched the previous Fsnext(). If
  290. you want to do Fsnext() until it fails, and you care about what was
  291. there before it failed, you have to copy it out.
  292.  
  293. You don't have to copy out ALL of the DTA, of course, just the public
  294. parts, and of that, just the parts you care about.
  295.  
  296. No part of the DTA needs to be saved or preserved if you don't want to
  297. do another Fsnext on it: there is no vital GEMDOS information there.
  298. Fsfirst completely reinitalizes the DTA (or returns "file not found" or
  299. "path not found").
  300.  
  301. ============================================
  302. Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
  303. reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt
  304.  
  305. ------------------------------
  306.  
  307. Date: 6 Nov 89 21:18:25 GMT
  308. From: imagen!atari!kbad@ucbvax.Berkeley.EDU  (Ken Badertscher)
  309. Subject: Trying to read an Atari St Gem-Dos disk on a Mac SE using FD/HD
  310.  
  311. pnh@pmin24.osf.org (Peter Harbo) writes:
  312. | I don't think it's possible w/ Apple File Exchange (I know it isn't, because
  313. | it recognizes the disks as MS/DOS, 720 K but can't read the directory
  314. | structure and only offers to format them)...
  315.  
  316. This could be because disks created on pre-Rainbow TOS versions would not
  317. correctly time/date stamp the "current" and "parent" directory entries.
  318. Some DOS machines have the same problem with ST disks.
  319. --
  320.    |||   Ken Badertscher  (ames!atari!kbad)
  321.    |||   Atari R&D System Software Engine
  322.   / | \  #include <disclaimer>
  323.  
  324. ------------------------------
  325.  
  326. Date: 6 Nov 89 20:46:19 GMT
  327. From: imagen!atari!apratt@ucbvax.Berkeley.EDU  (Allan Pratt)
  328. Subject: TT
  329.  
  330. ramsiri@blake.acs.washington.edu (Enartloc Nhoj) writes:
  331. >The strange thing is that i have a hard time believing that i
  332. >am still considering buying an 030 that won't multitask all that
  333. >niffty GEM software i have on my drive.
  334.  
  335. Why on Earth do you find this difficult to believe?  You clearly
  336. have not thought through the implications of a multitasking TOS.
  337.  
  338. What parts of the system are task-specific, and need to be switched
  339. with the task's context?  The CPU registers, sure, and GEMDOS's
  340. current-process pointer.  But what about the "Bconin() returns the
  341. shift key state" bit in _conterm?  What about the critical error
  342. handler?  What about the 200Hz interrupt vector (or, worse, something
  343. in the MIDDLE of the 200Hz interrupt vector chain)?
  344.  
  345. No multitasker can satisfy "all that nifty GEM software" you have. What
  346. CAN be done is this: we can lay down rules for multitasking, and write
  347. a multitasker within those rules, and programs written with those rules
  348. in mind will work.  Furthermore, programs written *without* those rules
  349. in mind, but which follow them anyway, will work.  Therefore the rules
  350. should be broad enough to cover a wide range of existing programs.
  351.  
  352. What I'm trying to say is THIS IS NOT EASY.  It's not even Moderately
  353. Difficult.  This is A Hard Problem.  The presence of a 68030 doesn't
  354. make it any easier.
  355.  
  356. ============================================
  357. Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
  358. reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt
  359.  
  360. ------------------------------
  361.  
  362. Date: 6 Nov 89 21:40:59 GMT
  363. From: imagen!atari!kbad@ucbvax.Berkeley.EDU  (Ken Badertscher)
  364. Subject: unix on the TT
  365.  
  366. covertr@force.UUCP (Richard E. Covert) writes:
  367.  
  368. | In article <1768@atari.UUCP>, kbad@atari.UUCP (Ken Badertscher) writes:
  369. | > depeche@quiche.cs.mcgill.ca (Sam Alan EZUST) writes:
  370. | > [ read in a magazine... ]
  371. | > | THE DESKTOP MODEL WILL NEVER WORK WITH UNIX only the TOWER will....
  372. | > | if this is true, WHY?????
  373. | > Because the magazines don't know what they're talking about.
  374. | I personally couldn't care less what you put on the TT/Plastic as I don't
  375. | plan to buy another Atari computer w/o plenty of card slots.
  376.  
  377. Perhaps I should clarify what I posted before.  I'm getting sick and
  378. tired of seeing rumors and misinformation bandied about as facts here
  379. and elsewhere.
  380.  
  381. If it's a TT, it'll run Unix.  It may require adding memory or disk storage,
  382. but it will run Unix.
  383.  
  384. I don't recall a public release of Atari specifications at all for any
  385. tower configuration of TT ever.  So if you read or write anything
  386. specific about any such machine, it's pure fabrication.
  387.  
  388. Subject to change without notice.
  389. Your mileage may vary.
  390. Do not remove tag under penatly of law.
  391. --
  392.    |||   Ken Badertscher  (ames!atari!kbad)
  393.    |||   Atari R&D System Software Engine
  394.   / | \  #include <disclaimer>
  395.  
  396. ------------------------------
  397.  
  398. End of INFO-ATARI16 Digest V89 Issue #614
  399. *****************************************
  400. =========================================================================